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ABSTRACT.  High-level  functional  (or  behavioral)  simulation  models  are 
difficult,  time-consuming,  and  expensive  to  develop.  We  report  on  a  method 
for  automatically  generating  the  program  code  for  a  high-level  functional  sim¬ 
ulation  model.  The  high-level  model  is  produced  directly  from  the  program 
code  for  the  circuit  components’  functional  models  and  a  netlist  description 
of  their  connectivity.  A  prototype  has  been  implemented  in  LISP  for  the 
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INTRODUCTION. 

Highly  complex  behavior  in  modern  VLSI  devices  is  attained  by  the  complex 
arrangements  of  simple  elements:  transistors  are  organized  into  inverters,  in¬ 
verters  into  flip-flops,  flip-flops  into  register  banks,  and  so  on  up  to  large  cir¬ 
cuits  such  as  microprocessors.  Verifying  the  correctness  of  complex  behavior, 
in  the  device  as  designed,  is  one  of  the  greatest  challenges  facing  the  indus¬ 
try  today.  Currently,  simulation  is  the  primary  method  used  to  verify  the 
correct  behavior  of  designs.  Circuit-level,  switch-level,  logic-level,  and  func¬ 
tional  (or  behavioral)  level  simulators  are  used  for  larger  and  larger  circuits. 
Higher-level  simulation  functional  models  are  important  to  reduce  simulation 
times  on  large  circuits.  They  are  also  important  for  comprehensibility:  a  sin¬ 
gle  high-level  functional  model  is  easier  to  understand  than  many  low-level 
models  and  a  description  of  how  they  are  connected. ^ 

Though  necessary  and  desirable,  functional  models  are  expensive,  diffi¬ 
cult,  and  time-consuming  to  develop  [10].  Because  of  the  cc»t  and  engineer¬ 
ing  effort  involved,  several  companies  have  even  begun  to  produce  functional 
simulation  models  commercially  [4,  17],  producing  both  component-level  and 
board-level  models.  There  is,  however,  a  more  insidious  aspect  than  time, 
difficulty,  and  expense:  that  of  error  in  the  functional  model.  The  problem 
of  verifying  the  correctness  of  the  device  to  its  specifications  has  been  trans¬ 
formed  to  the  problem  of  verifying  the  correctness  of  the  functional  model  to 
the  device. 

We  report  work  on  the  problem  of  automatically  generating  program  code 
for  the  higher-level  functional  simulation  model  of  the  device,  starting  with  a 
description  of  its  circuit.  This  will  allow  a  circuit  designer  to  create  a  design, 
abstract  it,  and  simulate  it  more  efficiently  at  a  higher  level. 

Our  approach  builds  on  Al-based  ideas  of  symbolically  manipulating  mul¬ 
tiple  representations,  which  we  applied  to  symbolic  representations  of  function 
and  time.  Key  ideas  include: 
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•  Multiple  representations  of  knowledge  about  behavior  and  time:  in  LISP 
code,  in  algebraic  equations,  and  in  an  event  formalism. 

•  Capturing  program  code  semantics  in  the  translation  between  represen¬ 
tations. 

•  Symbolic  reasoning  about  behavior  and  time. 

•  An  algebraic  symbol  manipulator  for  temporal  equations. 

•  Simplification  of  expressions  based  both  on  syntactic  form  and  on  time 
dependencies. 

A  LISP-based  prototype  (FUNSTRUX)  has  been  implemented  to  explore 
these  ideas,  and  produces  executable  simulator  program  code  comprising  the 
functional  model  of  a  circuit.  FUNSTRUX  is  written  in  LISP  and  runs  on  a 
Symbolics  LISP  machine.  Input  to  the  system  is  the  SIMMER  [21]  simulator 
functional  model  (coded  in  LISP)  for  each  circuit  component  type,  together 
with  a  net  list  description  of  circuit  connectivity.  Output  is  a  single  SIMMER 
functional  model  (also  coded  in  LISP)  of  the  circuit  as  a  whole. 

Project  goals  were  primarily  intended  to  demonstrate  this  basic  concept: 

•  Produce  a  single  abstract  functional  model  for  a  circuit,  from  its  compo¬ 
nent  functional  models  and  its  connectivity. 

•  Accept  executable  program  code  as  input  and  produce  executable  pro¬ 
gram  code  as  output. 

«  Real  functional  abstraction  must  be  done,  i.e.  the  abstract  model  may 
not  naively  re-encode  the  individual  simulations  of  its  components. 

•  The  functional  model  must  be  functionally  correct,  both  in  signal  val¬ 
ues  and  in  time  behavior,  with  respect  to  the  simulator  behavior  of  the 
components’  functional  models. 

•  The  program  code  must  be  “reasonable”,  and  must  speed  the  simulation, 
but  highly  optimized  code  was  not  a  design  goal. 

•  Appropriate  state  objects  and  manipulations  must  be  inferred  as  neces¬ 
sary  to  maintain  functional  correctness,  but  need  not  be  highly  optimized. 


We  have  used  this  prototype  to  automatically  generate  functional  models  for 
the  SCORE  [3]  standard  cell  library  generator  system,  as  well  as  a  functional 
model  of  a  2901  microprocessor  1-bit  slice  plus  control  logic  [2],  from  prim¬ 
itive  devices  such  as  latches,  clocked  inverters,  etc.  This  demonstrates  the 
prototype  capability  to  produce  both  a  standard  cell  functional  library  and  a 
complex  circuit  model  automatically  from  design  primitives. 

BACKGROUND:  STAR  SYSTEM  AND  SIMMER. 

FUNSTRUX  runs  as  one  component  of  the  STAR  design  system  [20],  and 
continues  an  investigation  into  function,  structure,  and  their  relationship. 
STAR  is  an  integrated  LISP-based  design  system  supporting  a  wide  vari¬ 
ety  of  powerful  tools,  designed  around  the  Y  model  proposed  by  Gajski  and 
Kuhn  [11].  The  heart  of  the  system  is  the  data  representation  schema  called 
the  Y-Database.  The  Y  Hardware  Description  Language  is  embedded  in  LISP 
and  is  similar  to  DPL,  except  that  it  has  been  extended  to  model  not  just 
physical  layout  information  but  also  structure  (blocks  and  connectivity)  and 
function.  The  data  representaton  is  object  oriented  and  uses  the  Symbol¬ 
ics  Flavor  system.  The  STAR  system  integrates  functional  simulation  (SIM- 
MER[21]),  netlist  manipulation  (CONSTELLATION[22])  and  parameterized 
cell  generators  (SCORE[3])  through  the  Y-Database. 

SIMMER  [21]  is  a  LISP-based  functional  simulation  system  which  mod¬ 
els  functionality  in  the  well-known  discrete-event-driven  framework.  Events 
(a  value  transition  at  some  port  or  state  object)  invoke  the  circuit  objects 
involved  to  execute  their  functional  models,  possibly  spawning  new  events 
as  these  propagate  new  values.  SIMMER  was  designed  primarily  as  an  ex¬ 
perimental  simulation  framework  to  facilitate  explorations  into  function  and 
structure  such  as  described  in  this  paper. 
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FUNCTION  FROM  STRUCTURE. 

FUNSTRUX  employs  three  different  representations  of  the  same  functional 
behavior,  each  useful  for  a  different  task:  code-based,  event-based,  and  equation 
based  (see  figure  1).  The  program  code  comprising  the  low-level  functional 
models  is  converted  to  an  event-based  representation,  using  the  circuit  connec¬ 
tivity  information.  The  events  are  converted  to  an  equation-based  temporal 
algebra,  and  then  merged  by  performing  the  indicated  substitutions.  One 
global  equation  is  generated  for  each  external  port,  and  one  for  each  internal 
state  variable  referenced  by  the  port  equations.  Simplifications  are  performed 
by  syntax-based  transformations.  The  resulting  global  equations  are  con¬ 
verted  back  to  the  event-based  representation.  State  objects  are  created  and 
value  references  resolved  between  state  objects  and  I/O  ports.  Finally,  the 
event-based  representation  is  converted  back  to  one  large  functional  program 
for  the  entire  structural  network. 


Figure  1.  The  FUNSTRUX  system  architecture.  Program  code  for  the 
functional  models  of  the  circuit  components  is  converted  to  equations  in 
a  temporal  algebra,  substituted  and  simplified  according  to  the  circuit 
structure,  and  converted  back  to  functional  model  program  code  for  the 
whole  circuit. 


Code-based  Representation  of  Behavior. 

The  code-based  representation  (figure  3)  is  the  executable  program  code 
making  up  the  SIMMER  functional  models  of  the  components.  (SIMMER 
code  is  essentially  LISP  code,  with  some  built-in  functions  which  read  and 
drive  busses,  and  get  and  put  internal  state  objects.)  Together  with  a  netlist 
description  of  component  connectivity  (generated  automatically  by  the  STAR 
system),  the  code-based  representation  is  the  primary  input  to  FUNSTRUX. 
It  is  also  the  final  output,  as  program  code  for  the  whole  circuit  is  produced. 

Composing  functional  models  from  the  program  code  is  difficult.  Event 
schedulings  are  buried  deeply  in  the  code,  usually  depending  on  widely-spaced 
conditional  assignments  to  local  variables  and  other  complications.  The  first 
transformation  is  to  convert  the  LISP-based  SIMMER  code  into  a  description 
of  the  events  (the  conditionalized  signal  transitions)  it  implies. 

Events  are  extracted  by  symbolically  executing  the  programmatic  func¬ 
tional  model.  At  each  point  in  the  symbolic  execution,  a  binding  stack  as¬ 
sociates  each  symbol  (variable)  with  a  symbolic  formula  which  computes  its 
value  at  that  point  from  constants,  bus  values,  and  state  objects.  A  condition 
stack  maintains  the  set  of  overall  conditionalizations  which  must  have  held 
for  that  point  of  the  code  to  have  been  reached.  This  allows  determination 
of  what  events  would  have  occurred,  under  what  conditions,  and  how  the  val- 


(DEFUN  CLOCKED- INVERTER' FCN  (SELF  Q  A  E) 
"outputs  NOT  A  to  (J  if  E>1 ,  sis*  tri-statee" 
(DRIVE-BUS  4  SELF  ‘(BIT)  (W  :*  :Z)) 

;;  ‘a’  gata  is  always  high  ispedanca  *  <*  Z> 
(DRIVE-BUS  E  SELF  ’(BIT)  (W  :*  :Z)) 

;;  ‘a’  gata  is  always  high  iwpedahce  *  <*  Z> 
(LET*  ((DELAY  1.7) 

; ;  wont  cass  E  to  Q  delay 
(A-STATUS  (READ-BUS  A  ’(BIT))) 

;;  the  *a’  input  —  data 
(E-STATUS  (READ-BUS  E  ’(BIT))) 

;;  the  ’a’  input  -  enable 

(Q-STATUS  (COND  ((■?  1  E-STATUS) 

(W  (NOT  A-STATUS) 

: DRIVE)) 

((-?  0  E-STATUS) 


(W  :*  :Z)) 


(T  (W  :X  : DRIVE) ) ) ) ) 


;;  drive  ‘q’  with  the  result  to  be  output 
(DRIVE-BUS  Q  SELF  ’(BIT)  Q-STATUS  DELAY))) 


Figure  3.  The  SIMMER  code  for  the  clocked  inverter.  The  LET*  estab¬ 
lishes  variable  bindings;  the  COID  selects  a  value  corresponding  to  the  first 
true  test  of  E-STATUS.  If  the  enable  line  (E)  is  logical  one,  the  input  (A)  is 
logically  negated  and  output  (Q).  If  E  is  logical  zero,  Q  is  high  impedance 
( :  *  :  Z) .  Otherwise  an  X  is  output. 

ues  involved  would  have  been  derived.  Program  code  semantics  are  captured 

based  on  the  class  of  LISP  form: 

•  Binding  forms,  such  as  SETQ  and  LET*,  alter  the  formula  symbolically 
bound  to  a  symbol  on  the  binding  stack. 

•  Conditional  forms,  such  as  COND,  IF,  UNLESS,  and  WHEN,  push  their  con¬ 
ditionals  onto  the  global  condition  stack  in  an  implicit  AND. 

•  SIMMER  input  forms,  such  as  READ-BUS  and  GET-MY-STATE,  return  val¬ 
ues. 


#  SIMMER  output  forms,  such  as  DRIVE-BUS  and  PUT-HY-STATE,  create 


events. 


•  The  SIMMER  conditional  DEPENDS-ON  form,  which  is  ignored  by  FUN- 
STRUX. 

•  All  other  (unknown)  forms  are  treated  as  “black-box”  functions  according 
to  the  semantics  of  pure  LISP. 

This  approach  allows  most  standard  unknown  forms  (such  as  special-purpose 
functions  coded  by  a  designer  for  a  particular  purpose)  to  be  handled  correctly, 
though  simplification  may  not  be  possible.  Forms  that  perform  side-effects 
(e.g.,  reading  or  setting  a  global  variable)  are  not  handled  correctly. 

Following  the  substitution  process  described  below,  the  resulting  global 
circuit  events  are  converted  back  to  program  code.  Events  which  schedule 
I/O  ports  generate  DRIVE-BUS  calls,  while  events  which  schedule  state  ob¬ 
jects  generate  PUT-MY-STATE  calls.  The  enablement  predicate  (:EP,  below) 
is  translated  into  the  appropriate  conditionalization,  and  the  input  variable 
names  (:CV)  are  used  to  generate  the  DEPENDS-ON  forms.  Any  “black-box” 
functions  are  simply  inserted  where  they  appear. 

FUNSTRUX  is  not  a  simulation  language,  and  so  does  not  attempt  to 
capture  the  semantics  of  the  hardware  directly.  Instead,  it  models  the  seman¬ 
tics  of  the  underlying  simulation  language,  to  produce  an  abstract  functional 
model  which  remains  faithful  to  the  component-wise  simulated  behavior  of 
the  circuit. 

Event-based  Representation  of  Behavior. 

The  event-based  representation  (figure  4)  highlights  signal  transitions.  It 
details  which  values  will  be  output  by  the  functional  model  at  any  invocation, 
conditionalized  by  which  predicates  must  be  true  to  enable  the  events.  It 
captures  the  implied  value  transitions,  specified  implicitly  by  the  program 
code,  in  an  explicit,  quasi-canonical,  easily-manipulable  form. 

Each  event  clause  represents  a  conditionalized  signal  transition  at  some 
port  or  state  object,  and  so  each  circuit  object’s  program  code  potentially 


(( :EV  ( :CV  (INV_IN_E  INV_IN_A)  :EP  T) 

(:  SCHEDULE  IRVJRJ)  :AT  1.7 
:EQUAL-TO 

(CORD  ((■?  1  IMVJM.E) 

(W  (NOT  IMVJMJO  : DRIVE)) 
((AMD  (-?  0  IHV_IH_E) 

(MOT  («?  1  INV_IN_E))) 
(VV  :*  :Z)) 

((AMD  T 

(MOT  (■?  0  INV_IM_E)) 
(NOT  (-?  1  invjemj:))) 
(W  :X  -.DRIVE)) 

(T  MIL)))) 

(:EV  (:CV  MIL  :EP  T) 

(: SCHEDULE  IMVJEMJ  : AT  0.0 
:  EQUAL-TO  (W  :*  :Z))) 

( :EV  ( :CV  MIL  :EP  T) 

(: SCHEDULE  IMVJNJl  : AT  0.0 
: EQUAL-TO  (W  :*  :Z)))) 


Figure  4.  The  events  generated  for  the  clocked  inverter.  The  meaning  of 
each  field  is  described  in  the  text. 

generates  several  event  clauses.  The  idea  is  that  when  either  the  enablement 
predicate  becomes  true  or  the  input  variables’  values  change  while  the  en¬ 
ablement  predicate  is  true,  the  value  assigned  to  a  port  or  state  object  is 
re-calculated  and  re-assigned.  Accordingly,  each  event  clause  defines  (where 
a  variable  represents  a  port  or  state  object  value): 

•  The  enablement  predicate  (:EP)  on  whose  leading  edge  the  event  occurs; 

•  A  list  of  the  input  variable  names  (:CV)  which  can  trigger  the  event  when 
their  values  change; 

•  Some  variable  name  (-.SCHEDULE)  which  is  the  recipient; 

•  The  non-negative  delay  (:AT)  associated  with  the  event; 

•  A  symbolic  formula  (:EQUAL-T0)  for  the  value. 


Equation- based  Representation  of  Behavior. 

The  equation  representation  (figure  5)  facilitates  composition,  simplification, 
and  reasoning  about  the  code.  Behavior  is  described  in  an  algebraic  notation, 
using  temporal  operators,  which  states  relationships  between  port  values.  This 
is  useful  because  algebraic  equations  can  be  easily  composed,  and  the  time 
behavior  of  components  easily  chained  together  and  reasoned  about. 

invJnjCJ(t)  =  ( cond  ((  =  ?  1  invJn^E(t  -  1.7)) 

(vv  (not  invJn-A(t  -  1.7)) 

;  drive)) 

((=?  0  invJn_E(t  -  1.7)) 

(vv  :  *  :  z)) 

(T  (vv  :x  -.drive)))) 
invJn_E(t)  =  (vv  :  *  :  z)) 
invJn-A(t)  =  (vv  :  *  :  z)) 

Figure  5.  The  equations  generated  for  the  clocked  inverter.  Each  port 
is  shown  as  a  time-dependent  function  of  the  time- varying  values  of  the 
other  ports.  Note  the  use  of  forms  like  COND,  which  are  well-defined 
mathematical  functions  as  well  as  LISP  language  forms. 

We  use  a  continuous  model  of  time,  and  so  there  is  no  “smallest”  timestep  as 
in  discrete  time  models.  The  specification  of  the  value  of  a  variable  (a  port  or 
state  object)  as  a  function  of  time  is  a  timeline.  We  view  devices  as  mappings 
on  timelines  (1,  19].  The  <=  (“left  arrow”)  operator  allows  reference  to  the 
most  recent  time  that  a  condition  (predicate)  was  true  [1,  23,  26].  Thus 

{<=(«)  (=?  1  K(«))  «-«)} 

returns  the  most  recent  time,  u  (a  formal  variable),  that  V(u)  was  equal  to 
logical  one,  but  prior  or  equal  to  the  time  (1  -  6). 


We  represent  function  by  LISP-like  algebraic  expressions  involving  no 
side-effects.  Thus,  a  zero-delay  inverting  D-Flip-Flop  could  be  represented  as 
Q(t)  =  (NOT  D((<=  (u)  (=?  1  CLOCKS))  (*)}))• 

This  says  that  the  value  of  the  output  Q(t)  is  the  logical  negation  of  the  input 
D(u),  where  u  is  the  most  recent  time  that  CLOCK(u)  was  logical  one,  but 
prior  or  equal  to  the  time  t. 

Though  this  facilitates  substitution  and  composition,  much  needless  re¬ 
dundancy  and  unused  code  is  introduced  by  these  operations.  This  results  in 
a  combinatorial  explosion  in  expression  size  unless  simplification  is  performed 
at  each  step.  We  have  a  database  of  simple,  syntactic  simplification  rules 
which  are  very  fast  to  use.  For  example,  (NOT  (NOT  A'))  simplifies  to  X. 

We  also  have  a  reasoner  which  is  capable  of  time-based  logical  reasoning 
for  simplification.  For  example, 

(  =  ?  0  A'({<=  (u)  (  =  ?  1  *(«))  «)})) 

simplifies  to  FALSE:  because  X  was  not  logical  zero  at  the  most  recent  time 
that  it  was  logical  one. 

Equations  may  be  converted  to  and  from  event  representation.  The  key 
insight  for  converting  events  to  equations  is  that  a  value  does  not  change 
between  events,  so  the  value  at  time  t  is  just  the  value  of  whichever  event 
expression  has  occurred  mo6t  recently.  By  constructing  a  predicate  which 
indicates  when  a  variable’s  value  last  changed,  we  are  able  to  reason  about 
the  last  time  an  event  would  have  triggered.  The  key  insight  for  converting 
equations  to  events  is  that  state  objects  may  be  created  to  conditionally  delay 
the  values  of  inputs  to  an  equation. 

There  are  a  number  of  other  issues  involved  in  time- based  reasoning, 
simplification,  and  the  handling  of  multiple  representations,  which  cannot  be 
presented  here  due  to  space  limitations.  Interested  readers  will  find  these 
discussed  more  fully  in  [16]. 


AN  EXAMPLE. 

Consider  the  simple  example  shown  in  figure  2,  contrived  to  demonstrate 
the  creation  of  state  objects  and  the  collapsing  of  intermediate  structure.  For 
this  example  we  will  model  two  drive  strengths,  :DRIVE  and  :Z.  (:Z  means 
“undriven”.)  We  will  model  four  signal  values,  1,  0,  :X,  and  means 

“no-value”,  and  is  used  to  model  a  high-impedance  gate.)  The  transmitted 
signal  is  a  value  vector  “(vv  <value>  <drive>)”. 

The  SIMMER  (LISP)  program  code  for  the  clocked  inverter  functional 
model  is  shown  in  figure  3.  This  code  is  converted  to  the  event  representation 
as  described  above.  The  events  are  an  explicit  standardized  encoding  of  the 
transitions  implicitly  specified  by  the  program  code,  as  shown  in  figure  4.  Each 
variable  name  represents  a  bus  port  or  a  state  object.  Events  are  described 
from  the  point  of  view  of  the  circuit  object  generating  them,  and  represent 
its  response  at  any  invocation. 

Next  the  event  representation  is  converted  to  an  algebraic  temporal  equa¬ 
tion-based  form,  as  shown  in  figure  5.  Variables  now  represent  (port  or  state 
object)  timelines  indexed  by  time-points.  Automatic  simplification  performed 
prior  to  substitution  has  removed  the  extraneous  clauses  (such  as  “(AND  T 
. . .)”  in  figure  4)  introduced  by  the  symbolic  execution. 

The  equations  from  all  the  blocks  and  busses  in  the  circuit  are  succes¬ 
sively  composed,  alternating  with  simplification  to  reduce  the  combinatorics 
of  intermediate  forms.  The  resulting  code  produced  for  the  example  circuit  is 
in  figure  6. 

As  an  experiment  in  functional  abstraction,  functional  models  were  writ¬ 
ten  for  the  primitive  devices  of  clocked  and  unclocked  inverters,  Nand  and 
Nor  gates,  non-inverting  tri-statable  drivers  and  latches,  and  a  one-bit  RAM 
cell.  These  were  used  to  compose  SCORE  cell  library  functional  models,  and 
also  assembled  into  a  full  2901  bit-slice  plus  control  logic.  Table  1  details  some 
results  of  abstracting  netlist-level  circuits  (netl)  to  a  single  functional  model 
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(DEPOT  PAPER-EX AMPLE-FCN  (IN  OUT  Ell) 

"generated  by  computer  from  circuit  structure" 
(DEPEVDS-OI  'MIL  ’ MIL 

(DRIVE-BUS  II  SELF  '(BIT)  (W  :•  :Z)  O.O)) 
(DEPEIDS-OV  'MIL  'MIL 

(DRIVE-BUS  EMA  SELF  '(BIT)  (W  :•  :Z)  0.0)) 
(DEPEMDS-OI  '(EMA)  'MIL 

(COMD  ((NOT  (LOGZERQ  (READ-BUS  EMA  '(BIT)))) 
(PUT-MY-STATE  SELF  ' (EMA-483) 

(READ-BUS  EMA  '(BIT))  0.0)))) 
(DEPEMDS-OM  '(EMA  II)  'MIL 

(COMD  ((MOT  (LOG ZERO  (READ-BUS  EMA  '(BIT)))) 
(PUT-MY-STATE  SELF  ' (11-465) 

(READ-BUS  II  '(BIT))  0.0)))) 
(DEPEMDS-OM  'MIL  ’ ((EM A- 462)  (11-484)) 

(DRIVE-BUS  OUT  SELF  ' (BIT) 

(W  (COMD  ((LOGO Ml 

(GET-MY-STATE  SELF  ’(ENA-482))) 
(LOG- MOT 

(GET-MY-STATE  SELF  ’(11-484)))) 
(T  :X)) 

: DRIVE) 

0.0)) 

(DEPEMDS-OI  'MIL  ’((IM-48S)) 

(PUT-MY-STATE  SELF  ’(IN-484) 

(GET-MY-STATE  SELF  ’(IM-486))  2.7)) 
(DEPEMDS-OM  'MIL  ’((EMA-483)) 

(PUT-MY-STATE  SELF  ’ (EMA-482) 

(GET-MY-STATE  SELF  ’(EMA-483))  2.7))) 


Figure  6.  The  program  code  generated  for  the  example  circuit  of  figure  2. 
The  clocked  inverter  delay  is  1.7  and  the  unclocked  inverter  delay  is  0.5, 
yielding  1.0  for  the  final  unclocked  inverter  pair.  DEPENDS-ON  sup¬ 
presses  activity  unless  one  of  the  bus  list  or  state  list  values  has  changed. 


(fcnl).  Simulation  data  is  foT  identical  inputs  during  the  same  simulated  time 
period,  running  SIMMER  on  a  Symbolics  LISP  machine.  Because  the  project 
goals  were  mainly  to  demonstrate  the  concept,  not  to  optimize  the  perfor¬ 
mance  of  the  code  module  produced,  the  data  should  be  taken  as  indicating 
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trends  only.  Even  so,  the  performance  improvement  is  clear  and  substantial. 

Since  the  functional  models  were  generated  only  from  the  structure  of 
component  primitives  they  are  guaranteed  to  be  true  to  the  device  as  designed; 
and  since  the  process  can  be  completed  in  a  day,  it  is  inexpensive  and  available 
quickly. 


Circuit 

No.  of 
Blocks 

No.  of 
Busses 

FUNSTRUX 

Time 

Example  of  figure  1  (net!) 

3 

2 

— 

U 

(fcnl) 

1 

0 

10  sec. 

D-Flip-Flop  w/S,  R  (netl) 

7 

5 

— 

U 

(fcnl) 

1 

0 

85  sec. 

2901  fiP  1-bit  6lice  (netl) 

370 

365 

— 

U 

(fcnl) 

1 

0 

7  hre. 

Circuit 

SIMMER 

Time 

Events 

Processed 

Function 

Invocations 

Example  of  figure  1  (netl) 

47  sec. 

1412 

606 

U 

(fcnl) 

11  sec. 

873 

413 

D-Flip-Flop  w/S,  R  (netl) 

50  sec. 

5883 

1404 

a 

(fcnl) 

34  sec. 

2432 

846 

2901  /iP  1-bit  slice  (netl) 

1083  sec. 

16303 

6376 

U 

(fcnl) 

287  sec. 

2055 

690 

Table  1.  Some  timing  results  for  netlist  (netl)  and  abstracted  (fcnl)  cir¬ 
cuits. 


DISCUSSION:  MULTIPLE  PARADIGMS  OF  FUNCTION 
AND  BEHAVIOR. 

Every  attempt  to  model  the  real  world  is  necessarily  an  approximation,  and 
every  approximation  rests  on  a  number  of  underlying  assumptions.  Let  us  call 


the  set  of  assumptions  underlying  a  related  group  of  device  functional  models, 
a  “functional  paradigm”.  Often  the  functional  paradigm  is  imposed  by  the 
execution  semantics  of  the  simulator  on  which  the  device  models  are  run. 

One  of  the  first  realizations  of  our  research  was  the  great  multiplicity 
of  distinct,  but  coherent  and  conceptually  adequate,  functional  paradigms. 
Interactions  must  be  carefully  considered  to  insure  that  the  abstract  func¬ 
tional  model  produced  is  functionally  equivalent  to  the  behavior  of  the  circuit 
components  in  the  simulator.  For  example,  many  different  bus  models  have 
been  proposed:  global  variable,  wired  OR,  RC  tree,  uni-/bi-directional  trans¬ 
mission  line,  delay  line,  and  many  others.  The  choice  of  bus  model  must  be 
consistent  with  the  underlying  simulator  semantics,  and  the  device  models 
must  be  consistent  with  both  of  these.  The  process  of  functional  abstraction 
must  be  consistent  with  all  three  simultaneously.  Examples  of  other  points  to 
consider  include: 

•  The  notion  of  “function”  can  be  understood  in  several  ways. 

•  Time  might  be  modeled  as  continuous  (infinitely  divisible)  or  as  discrete 
(some  minimum  time-step  size). 

•  The  handling  of  values  at  the  endpoints  of  intervals  on  timelines  might 
adopt  a  convention  of  (a,  ft],  or  [a,  ft),  or  simply  encode  the  transition  in 
the  instantaneous  value.  (In  FUNSTRUX,  the  event  representation  uses 
a  [a,  ft)  formalism  and  the  equation  representation  uses  a  (a,  ft]  formalism, 
to  facilitate  manipulation.) 

•  There  are  several  different  ways  that  future  (pending)  event  en-/dequeual 
might  be  handled. 

«  Zero-delay  elements  can  be  modeled  in  any  of  several  ways;  they  have  no 
physical  reality,  but  are  often  convenient. 

•  There  are  several  rational  ways  that  appropriate  state  objects  could  be 
inferred. 

a  Ports  and  signal  flow  can  be  unidirec  tional  or  bidirectional. 


•  Signals  might  model  the  signal  value  only,  or  value  plus  drive  strength, 
or  some  other  combination. 

This  list  is  indicative  rather  than  exhaustive.  The  point  is  that  there  are 
several  closely-related  but  alternative  functional  paradigms,  each  internally 
coherent,  and  each  consistent  with  different  underlying  simulator  behavior. 

SHORT-COMINGS,  LIMITATIONS,  AND  FUTURE  WORK. 

Zero-delay  loops  in  the  circuit  become  ill-constrained,  because  a  component’s 
behavior  can  then  conceptually  contribute  to  determining  its  own  behavior. 
Currently  we  disallow  all  zero-delay  loops  (as  do  most  simulators).  Also,  in 
the  case  of  a  pass  transistor  network  (passive  steering  logic)  we  currently  do 
not  correctly  model  global  network  properties  such  as  drive  strength.  This 
situation  does  not  arise  in  the  standard-cell  circuits  we  considered.  The  re¬ 
strictions  we  imposed  on  the  class  of  circuits  considered  are: 

•  Busses  connect  only  to  blocks. 

•  Busses  change  state  only  when  directly  driven  by  a  block. 

•  Zero-delay  loops  are  disallowed  (this  excludes  zero-delay  bidirectional  el¬ 
ements  as  a  special  case). 

Extensions  beyond  this  restricted  case  are  a  very  challenging  open  problem 
for  future  research. 

The  creation  of  state  objects  is  still  rather  unsatisfactory.  We  have 
explored  dependency-graph  analysis  methods,  simulated  annealing,  Markov 
walks,  and  more  ad  hoc  approaches.  All  tend  to  result  in  the  creation  of  more 
state  objects  than  strictly  necessary.  Optimal  state  object  creation  is  more 
general  than  the  problem  of  deleting  the  minimum  number  of  graph  nodes  to 
break  all  feedback  cycles,  which  is  known  to  be  computationally  intractable  (it 
reduces  to  Feedback  Vertex  Set  [12]).  So  are  the  subsidiary  problems  of  iden¬ 
tifying  the  node  through  which  the  most  simple  cycles  pass,  or  even  counting 
how  many  distinct  simple  cycles  pass  through  a  given  node  (both  reduce  to 


Kth  Shortest  Path  [13]).  Perhaps  a  careful  analysis  of  how  human  designers 
allocate  state  objects,  or  an  approach  like  “plunking”  [7],  would  lead  to  a 
better  algorithm. 

The  code  produced  has  not  been  optimized  for  human  readability,  but 
rather  is  organized  in  a  way  that  reflects  the  functional  composition.  This  is 
undesirable  because  we  would  like  to  be  able  to  easily  inspect  the  higher-level 
code  produced  in  order  to  help  debug  faulty  circuit  designs. 

Because  a  fundamental  aspect  of  this  work  is  that  it  abstracts  function¬ 
ality  directly  from  the  structure  of  the  circuit,  it  can  not  be  used  to  produce  a 
functional  model  of  a  circuit  until  after  the  circuit  structure  has  been  designed. 
However,  if  a  top-down  circuit  design  methodology  is  employed  intermediate 
functional  models  could  be  abstracted  from  intermediate-level  components. 

We  have  not  yet  incorporated  error  detection  and  exception  reporting 
mechanisms.  This  could  easily  be  done  by  including  dummy  components 
(“monitors”)  in  the  circuit,  connected  to  the  signals  to  be  checked,  with  a 
functional  model  which  called  some  function  to  check  the  signals  and  re¬ 
port  as  appropriate.  Because  FUNSTRUX  simply  passes  unknown  functional 
forms  directly  through  as  a  “black  box”,  any  such  special-purpose  error  func¬ 
tions  would  simply  be  composed  with  the  overall  abstract  functional  model, 
whenever  they  were  encountered  in  the  circuit. 

This  work  is,  of  course,  preliminary.  Future  work  will  involve  trying  to  ex¬ 
tend  the  abstraction  mechanisms  reported  here  to  encompass  a  wider  range  of 
functional  simulation  languages.  We  intend  to  attempt  at  least  one  commer¬ 
cial  (production-quality)  functional  simulator,  and  to  automatically  generate 
simulator  models  for  it  from  primitive  elements.  We  would  like  to  recognize 
higher-level  roles  from  low-level  implementations.  For  example,  FUNSTRUX 
will  correctly  compose  the  functional  models  of  the  components  of  an  adder 
to  produce  a  higher-level  model  which  correctly  models  the  adder,  bitwise, 
but  cannot  recognize  that  a  simple  integer  “+”  could  be  directly  substituted. 


Another  desirable  area  would  be  the  ability  to  incorporate  simplifying  as¬ 
sumptions  about  the  surrounding  circuitry  or  signals. 

RELATED  WORK. 

The  critical  need  to  verify  the  functional  correctness  of  complex  designs  is 
well  known.  Simulation  is  an  important  part  of  practical  correctness  verifica¬ 
tion,  so  much  so  that  there  are  over  100  languages  for  simulation  and  behavior 
[9].  Several  companies  produce  functional  simulation  models  commercially  [4, 
17].  Various  temporal-based  systems  attempt  to  capture  the  time  behavior 
of  circuits  using  logical  axioms  or  equations  [1,  18,  23,  25,  26].  Schwartz 
and  colleagues  [25,  26]  used  the  <=  temporal  operator  to  reason  about  com¬ 
munication  protocols.  Hunt  and  Moore  [18]  used  temporal  logic  to  verify  a 
microprocessor.  Amblard  et  al.  [1]  proposed  an  equivalent  representation  to 
our  equations  for  reasoning  about  circuits,  but  did  not  implement  the  method 
and  did  not  relate  it  to  simulation.  Meinen  [23]  used  a  notation  similar  to 
our  enablement  predicate  (:EP),  showed  that  every  group  of  edge-controlled 
transfers  can  be  written  as  a  group  of  interval-controlled  transfers  and  vice 
versa,  and  proposed  that  an  event-based  simulation  could  be  automatically 
constructed  from  an  extracted  circuit.  To  our  knowledge,  however,  our  work 
is  the  first  to  produce  executable  functional  model  program  code  for  a  circuit 
automatically  from  the  executable  program  code  of  the  circuit  components. 

This  research  also  contributes  to  systems  which  try  to  understand  how 
circuits  work.  It  is  a  start  at  understanding  the  analytical  knowledge  necessary 
to  complement  Hall’s  work  on  learning  [14,  15].  Kelly  and  Steinberg  [19] 
explored  functional  composition  using  timelines.  Mitchell  [24]  showed  how  a 
functional  explanation  could  be  used  to  learn  design  rules  in  a  design  grammar. 
Sussman  [28]  advanced  the  notion  of  multiple  representations  of  sub-circuits 
and  components. 

Several  hardware  diagnostic  systems  have  combined  structure  and  func¬ 
tion  [6,  8).  These  systems  are  usually  directed  at  the  board  level  rather  than 


VLSI  circuits.  Shirley  [27]  used  structure  and  behavior  information  to  design 
tests  for  VLSI.  Darlington  [5]  used  a  transformational  approach  to  optimizing 
program  code  which  is  conceptually  similar  to  our  syntactic  simplifications. 

SUMMARY  AND  CONCLUSIONS. 

The  behavior  of  a  circuit  is  implicit  in  the  behavior  of  its  parts  and  their 
structural  connections.  We  have  investigated  the  abstraction  of  function  from 
structure  in  VLSI,  and  mapped  out  a  mechanism  for  doing  this  with  one 
functional  simulator.  A  LISP  prototype  (FUNSTRUX)  was  implemented  to 
experimentally  investigate  this  possibility.  Input  is  the  program  code  for  the 
functional  models  of  the  circuit  components,  together  with  a  netlist-like  de¬ 
scription  of  their  connectivity.  Output  is  the  program  code  for  a  single  func¬ 
tional  model  of  the  circuit  as  a  whole.  FUNSTRUX  was  used  to  automatically 
create  SIMMER  functional  models  for  the  SCORE  standard  cell  library.  We 
also  used  FUNSTRUX  to  generate  a  functional  model  for  a  2901  micropro¬ 
cessor  1-bit  slice  plus  control. 

Some  of  the  key  points  in  this  functional  model  abstraction  process  in¬ 
clude: 

•  Knowledge  about  behavior  and  time  is  encoded  in  specialized  represen¬ 
tations  suitable  for  specialized  manipulations:  in  LISP  code,  in  algebraic 
temporal  equations,  and  in  an  event  formalism. 

•  Program  code  semantics  are  encoded  by  the  translation  to  and  from  the 
event  formalism. 

•  The  event  formalism  makes  explicit  and  manipulable  the  signal  transi¬ 
tions  implicit  in  the  program  code. 

•  Temporal  operators  and  equations  facilitate  substitution  and  composi¬ 
tion,  as  well  as  reasoning  about  time  dependencies. 

•  A  rule-based  system  is  used  for  simplification  of  expressions,  which  can 
be  easily  customized  for  specialized  syntax. 
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•  Unknown  forms  and  procedures  inserted  in  the  code  are  treated  according 
to  the  semantics  of  pure  LISP,  easily  accommodating  special-purpose 
functions  written  by  a  designer. 

•  State  objects  and  accessors  are  inferred  els  necessary. 

•  Dependency  analysis  allows  conditionalized  suppression  of  simulator  ac¬ 
tivity  unless  values  may  have  changed. 

We  hope  that  this  approach  captures  important  features  of  many  event-driven 
simulation  models,  and  so  will  be  reasonably  general  els  we  go  to  other  sim¬ 
ulators/languages.  Ideally,  a  wide  variety  of  event-driven  simulators  will  be 
expressible  in  an  event  notation  in  a  way  that  is  largely  independent  of  partic¬ 
ular  coding  conventions  of  particular  programmatic  function-describing  lan¬ 
guages  and  simulators.  This  would  permit  much  of  the  system  machinery 
to  be  re-tsirgeted  at  a  new  simulator  by  simply  re-writing  the  code-based  to 
event-based  translator,  rather  than  redeveloping  a  whole  new  system. 
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